Hi FYI,

I was playing with Restore DC Visuals on the hijack menu the other day when, following a reboot, the player (just the player software itself - seemingly playing a track but in fact not, no menu response, but hijack/kernel were alive and I could kill the player if I got in a ctrl-c early enough following a reboot before it started opening its database files) became stuck. It could no longer remount /dev/hda4 re-writeable either without blocking pretty much forever, although the filesystem was marked clean. I was able to remove and test the disk, at which point in my frustration, I simply reformatted it and re-installed. The disk seemed perfectly ok on a desktop Linux box.

Not yet had time to look, but I'm assuming that hijack uses the config file in /drive0/var/config and does some file related system calls directly from in-kernel. I don't see how that could have broken the filesystem, but perhaps some state was saved that caused the player software to become unhappy.

Just an FYI.

Jon.

And you're sure it wasn't just this well-known issue?

I have trouble believing that Hijack's behavior could screw up the filesystem to the point of sticking the player like that, especially after a power cycle. That kind of bug would not be characteristic of Mark's work on the kernel to date.

Nah, it was playing a track it had played...er (let's just say) "many" times before Oh, and I'm not criticising Mark...hijack is a thing of beauty. I'm just wondering if it might for example ever cause a filesystem to get remounted read-write to update a settings file, and (for example) therefore react badly to a power failure...or similar. I haven't poked enough yet.

You're the first person to have this problem if it is something to do with Mark's kernel.

It just reads the config file. It doesn't write it. Most of the settings are kept in flash.

No. Never.

So Mark, can you think of conditions under which the above could occur?

The kernel normally "blocks" mounting of /dev/hda4 while it does a filesystem check -- this gets triggered frequently after the max-mount count or max-mount time expires. When mounting manually, use the "nocheck" option to skip such unnecessary checks (which is what Hijack causes to happen on the player itself when the Filesystem Check on Sync menu entry is used.

For the original problem of the player "sticking", it's probably just a corrupted mp3, or bad data in the corresponding sector of the dynamic data partitiion --> which the player software DOES write to under normal operation.

-ml